常見的日誌收容機制，如昨天介紹的我們會以 SIEM 視角區分主動跟被動型的機制，
像是 Syslog 與 SNMP 屬於被動型 (Inbound) 蒐集機制，
而 JDBC、Log file、SMB 或 API 則屬於主動型 (Outbound) 蒐集機制。
而關於特定的解決方案因為廣為流行之後，也會成為一種日誌回傳的格式，
像是 Arcsight 使用的 CEF 格式，或是現在極為普遍的 JSON 機制等等。
都是現在蒐集系統日誌非常流行跟常見的做法。
通常不管是網路設備、作業系統，現在都基本上能夠設定事件轉拋的機制，
最基本面都會有 Syslog 的機制來蒐集的大多數資通訊系統的日誌。
通常比較會有疑問的會出現在各式的作業系統如何收集。
以下我們舉 Splunk 跟 IBM QRadar SIEM，
在各個作業系統是如何收集日誌的，做個實務應用上的說明與分享。
Splunk 是市場上非常流行的 SIEM 的解決方案，
它提供了在不同作業平台的蒐集器 (Agent) 版本可以直接在系統上安裝，
在產品面上會稱呼為「Universal forwarder」的角色，
透過 forwarder，除了可以支援監控本機端的系統日誌之外，
也能夠針對特定想要監控的檔案目錄、檔案內容來轉成 Event 拋送到 SIEM，
在自身曾經操作的實務經驗上，這樣的角色設計非常好用的管理非常多的端點，
同時也能夠透過中控台來管理 Agent 的健康狀態，以及規則是否要重新派送等等，
可以協助在很多不同異質平台進行日誌蒐集與監控。
IBM QRadar SIEM 也是目前市場非常流行的企業級的 SIEM 解決方案，
它則針對在 Windows 平台推出專屬的監控機制：「WinCollect」的機制，
支援 Agent / Agent-less 機制來部署、各有它適用的情境條件。
在一個典型的 500台 Windows 端點作業的企業場景，
我們可以使用主要幾台 Windows Host 安裝相關 Agent，
其他的 Windows 則是透過內建的 Windows Event Forwarding 機制蒐集，
統一遞送、彙整在有安裝 WinCollect 的核心主機後再拋送給 QRadar SIEM，
透過 WinCollect 來調整監控系統中的條件、政策與相關設定。
在常見的 Linux 系統或非 Windows 平台，
基本上都是透過系統日誌轉送機制 (Syslog UDP 514)，
而無論是在 Splunk 或 QRadar SIEM 的平台，
都能夠在接收到日誌後、進行日誌內容識別、正規化與儲存；
另一方面也是 Linux kernel 核心版本過多，
大多數僅能為主流版本打包支援的 Library，
故在實務上都會以 Agentless 的方式進行 Linux 作業系統日誌蒐集，
再透過日誌事件更新的週期或頻率，間接監控系統端短的健康存活狀態。
當然現在端點解決方案，
不管是防毒 (Anti-Virus) 或是偵測與回應 (EDR)，
都開始能夠支援 Windows / Linux / Mac 的 Agent 安裝與監控。
這部分就會牽涉各家端點解決方案的產品競爭優勢，
如果全都錄，會造成端點效能不佳、網路頻寬資源消耗、事件儲存空間不足，
如果部分錄，端點的可視化程度可能就會不足、可能遺漏關鍵事件紀錄，
且日誌蒐集完後，如何判斷是否為威脅？
如果人來看，牽涉客戶環境是否允許分析師接觸？
如果機器來看，使用技術能否有效偵測異常行為？
這些都會是在整體威脅關聯分析的環節時會再需要考量與探討的。
但無論如何，現在推陳出新的的端點解決方案，
都能夠很大幅度的改善 SIEM 傳統在端點這環的可視性與威脅操作的能動性。
補足以往 SIEM 解決方案被詬病只能被動收集日誌、
無法有效因應事件威脅採取相應動作的短板。
繼昨天我們簡單分享了日誌收集的流程後，
今天我們聚焦在日誌蒐集的通訊協定的探討，
同時以在 Windows/Linux 平台蒐集機制為例來說明，
最後也聊到端點解決方案之於現在 SIEM 的互補與強化。
明天我們就會進到 SIEM 日誌收容技術 III，
我們會分享日誌收集時所需要考慮的環節以及成本花費，
來讓邦友們更了解建置 SIEM、開使收集日誌後，
還需要考慮到哪些事情。
鐵人賽第六天，希望能獲得你/妳繼續的支持系列文章，
也感謝你的閱讀時間，開心能讓你對 SIEM 又多了些瞭解。
iThome鐵人賽
看影片追技術